Add query route method support#60655
Conversation
| */ | ||
| public function query($uri, $action = null) | ||
| { | ||
| return $this->addRoute('QUERY', $uri, $action); |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
I don’t believe HEAD should be added here
Laravel’s get() registers HEAD because RFC 9110 defines HEAD as identical to GET except no response body. RFC 10008 defines QUERY as its own method whose semantics depend on request content, so a HEAD request would not be equivalent to a QUERY request.
This also keeps it consistent with options(), which is safe but does not automatically register HEAD. Route::any() still includes both HEAD and QUERY through Router::$verbs.
There was a problem hiding this comment.
Gotcha! Thanks for the explanation 👍🏻
|
Concept first mentioned by issue #60564 ; not sure why it was a good idea to convert it into a discussion topic. |
|
I think it would make sense that it went in Ideas because QUERY is a new HTTP method and adding a first-class route helper is a framework API addition. At the same time, Laravel already has first-class helpers for common HTTP methods and QUERY now has a published Standards Track RFC. So I opened #60655 with a routing support-focused implementation: Route::query() If the maintainers decide this should be included in the Laravel framework, this PR should address the original issue without extending the scope outside of routing. |
3 participants
Re-targeting this to
masterafter feedback on the previous PR (#60650).This PR adds first-class routing support for the HTTP
QUERYmethod.Laravel already supports custom methods through
Route::match()andRouter::addRoute(), but there is no nativeRoute::query()helper like there is forget,post,put,patch,delete, andoptions.With this change, applications can define
QUERYroutes directly:QUERY is also included in Route::any(), exposed through the route registrar and facade docs, and treated as a read request by PreventRequestForgery.
That last part is important because QUERY is defined as a safe HTTP method, so it should behave like GET, HEAD, and OPTIONS for CSRF purposes.
Tests cover direct router dispatching, route registrar usage, framework integration, cached routes, and CSRF middleware behavior.